1. Technical Field
The present disclosure relates to business performance management, and more specifically, to modeling a slow changing dimension or type2 dimension of its corresponding high level data warehouse model and its automatic management using model driven business performance management.
2. Description of Related Art
Model driven business performance management (BPM) is becoming an integral part of enterprise software portfolios in many large organizations. Models enable a flexible approach to define and manage business metrics, which monitor and issue alerts when encountering a situation, all abstracted at the business level.
BPM models may be categorized into three types, including observation, data warehouse and dashboard models. The observation model defines modeling elements that capture monitoring and alerting requirements. The data warehouse model captures historical data of the monitoring elements and the dashboard model captures reporting requirements.
These models are made up of well defined elements that are complete and unambiguous in nature. Common elements among the BPM models include metrics, maps and dimensions.
Turning now to an exemplary business problem: As a business grows and its usage of BPM ages, data that seemed static (organization, departments, etc) starts to change over time. The definition of relatively static data may also change to reflect the growth in a particular area of business.
From an analytical point of view one needs to keep track of the old definition and updated definition for this relatively static data. The business may need to look into a history of the current year and past years for the analysis, financial reporting, etc. Not being able to relate the data because of changes over time can make the analysis difficult. This problem could become more difficult if an underlying information technology (IT) system is not capable of handling change.
With respect to the data warehouse, the relatively static data is typically called dimensional data and such changes are termed as slow changing dimension. Typically data warehouse solutions are built manually and take into account changes by modifying the dimension definition to accommodate the changes. But such activity is manual in nature, requiring time and capital to manage the data.
Existing data warehouse models, e.g., a visibility model, in BPM do not provide any provision to reflect slow changing dimension requirements at a business solution modeling level.
If an attribute of a dimension changes, the existing solution in the runtime overrides the value. Thus, from the history point of view, the meaning of the data is lost.
For example consider a dimension called Division:
Original data (Date=1Q2006): DivID=24,
DivName-Printers, DivHQ=New York (DivID is primary key)
Modified data (Date=3Q2006): DivID=24,
DivName-Computer Peripherals, DivHQ=New York
Modified data (Date=1Q2007): DivID=24,
DivName-Computer Peripherals, DivHQ-Hartford
In the above example, since both the DivName and DivHQ have been updated with time, any measurement associated with the DivID=24 in the past has lost the context. For example if one goes in the history of 1Q2006, the Div Name will read “computer peripherals” not “printers” as the data in dimension has no records for “printers,” which was overridden.
Therefore, a need exists for extending a data warehouse model to capture slow changing dimension requirements that preserves the semantics of the dimension attribute definition as well as historical data. The auto code generation component also needs to be updated to reflect the appropriate data structure for slow changing dimension and corresponding ETL (extract, transform, load) scripts that populate the dimensional table during execution time.